Moving to QA 🚀

(1) [FIXED]

1. User1 is manager of the space
2. User1 choose Edit image
3. Before choosing an image, another space manager downgrades User1 to viewer
4. User1 submit the image

Current:

No feedback in the app, there is no image change and no error message (just in the uploads view)

Expected:

As other handled errors, an snackbar would tell the user about the issue

NOTE: theoretically, it should work the same by changing to editor, but, backend allows the image update. IMO, this is a bug in the backend. I will create an issue there -> owncloud/ocis#11794

Xiaomi Redmi 13, Android 15
0749466fb

(2) [WONT FIX]

1. A user with permissions click on Edit image
2. Remove device connection
3. Pick a image -> enqueued
4. Recover device connection

Current:

Upload is done, image is uploaded, but space image is not updated. There is no PATCH request after the successful PUT

Expected:

Space image updated.

Xiaomi Redmi 13, Android 15
0749466fb

Just as a comment: i detected a 7MB limit for the space image. A larger image will not update, but, a success is returned. Pointing to another server issue...

owncloud/ocis#11832

(1) should be fixed with the last commit @jesmrec

About (2), there are two different scenarios:

1st scenario

1. A user with permissions click on Edit image
2. Remove device connection
3. Pick a image -> QUEUED
4. Recover device connection
5. Stay in the spaces list

In this case, the space image will be updated automatically once the upload is completed after the connection is recovered.

2nd scenario

1. A user with permissions click on Edit image
2. Remove device connection
3. Pick a image -> QUEUED
4. Navigate to other view
5. Recover device connection

In this case, the image will be uploaded to the .space directory but the space image won't be updated. This happens because the selectedImageName variable (inside SpacesListFragment) is reset while navigating. As a result, once you return to the spaces list, the remote transfer path will not match with the selected image name and the PATCH operation isn't triggered. Due to technical limitations related to navigation, fragment lifecycle, and activity handling, I don’t have a clear solution for this at the moment. Anyway, it's a corner case and there is no data-loss, so probably we can assume this problem until we have a potential fix. What do you think, @jesmrec? 🤔

Potential solutions discarded

1. When a transfer has the status QUEUED or FAILED the PATCH operation isn't performed. Problem: every transfer goes through the QUEUED status before IN_PROGRESS regardless of whether the connection is lost or not.

About the message just above ⬆️ ⬆️

In order to reproduce the problem:

1. User has initially connection, that allows to click on Edit image
2. Then, user loses connection while the image is chosen
3. After submitting, user must change the view, otherwise the problem is not reproducible.

Problem: image not updated

User must repeat the operation under connection (low impact side-effect)

As @joragua said, there is no critical problem at all. But the solution carries a big complexity to achieve a small piece of improvement. So, i'd go to mark it as known problem.

Approved from my side.

Known problem: #4705 (comment)